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(54) Public key infrastructure 



(57) A PKI (30) includes an off-line registration au- 
thority (38) that issues a first unsigned certificate (60) to 
a subject (34) that binds a public key (62) of the subject 
to long-term identification information (63) related to the 
subject and maintains a certificate database (40) of un- 
signed certificates in which it stores the first unsigned 
certificate. An on-line credentials server (42) issues a 
short-term disposable certificate (70) to the subject that 
binds the public key of the subject from the first unsigned 
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certificate to the long-term identification information re- 
lated to the subject from the first unsigned certificate. 
The credentials server maintains a table (44) that con- 
tains entries corresponding to valid unsigned certifi- 
cates stored in the certificate database. The subject 
presents the short-term disposable certificate to a veri- 
fier (36) for authentication and demonstrates that the 
subject has knowledge of a private key corresponding 
to the public key (46) in the short-term disposable cer- 
tificate. 
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Description 

[0001] The present invention relates to public key 
cryptosystems, and more particularly, to a lightweight 
public key infrastructure employing disposable short- 
term certificates for authentication and/or authorization. 
[0002] Public key cryptosystems are globally de- 
ployed on the World Wide Web. as well as on a growing 
number of enterprise networks, for establishment of se- 
cure communication channels. Every user in a public 
key cryptosystem has a pair of keys including a public 
key and a private key. The public key is disclosed to oth- 
er users while the private key is kept secret. A public 
key cryptosystem typically has a primary designed use, 
such as for encryption digital signature, or key agree- 
ment. Public key cryptosystems are also used for user 
authentication. For example, a user can authenticate it- 
self to other users by demonstrating knowledge of its 
private key, which other users can verify using the cor- 
responding public key. 

[0003] In an application of a public key cryptosystem 
for authenticating a user, the public key must be secure- 
ly associated with the identity of the user that owns the 
public key by authenticating the public key itself. Public 
key certificates are typically employed to authenticate 
the public key. A public key certificate is a digital docu- 
ment, signed by a certificate authority, that binds a public 
key with one or more attributes that uniquely identify the 
owner of the public key. The public key certificate can 
be verified using the certificate authority's public key, 
which is assumed to be well known or is recursively cer- 
tified by a higher authority. For example, in a corpora- 
tion, a public key certificate can bind a public key to an 
employee number. 

[0004] A public key infrastructure (PKI) refers to the 
collection of entities, data structures, and procedures 
used to authenticate public keys. A traditional PKI com- 
prises a certificate authority, public key certificates, and 
procedures for managing and using the public key cer- 
tificates. 

[0005] One type of a user of a PKI owns the public 
key contained in a public "key certificate and uses the 
certificate to demonstrate the user's identity. This type 
of user is referred to as the subject of the certificate or 
more generally as the subject. Another type of user re- 
lies on a public key certificate presented by another user 
to verify that the other user is the subject of the certifi- 
cate and that the attributes contained in the certificate 
apply to the other user. This type of user that relies on 
the certificate is referred to as a verifier or relying party. 
[0006] The association between a public key and an 
identity can become invalid because the attributes that 
define the identity no longer apply to the owner of the 
public key, or because the private key that corresponds 
to the public key has been compromised. A PKI typically 
employs two complementary techniques for dissociat- 
ing a public key from an identity. In the first technique, 
each public key certificate has a validity period defined 



by an expiration date, which is a substantial period from 
the issue date, such as one year from the issue date. In 
the second technique, the certificate authority revokes 
a public key certificate if the public key certificate's bind- 
5 ing becomes invalid before the expiration date. One way 
of revoking a public key certificate is by including a serial 
number of the public key certificate in a certificate rev- 
ocation list (CRL), which is signed and issued by the cer- 
tificate authority at known periodic intervals, such as 
every few hours or once a day. An entity that relies on 
a certificate is responsible for obtaining the latest ver- 
sion of the CRL and verifying that the serial number of 
the public key certificate is not on the list. 
[0007] CRLs typically become quite long very quickly. 
When the CRLs become long, performance is severely 
impacted. First, CRL retrieval consumes large amounts 
of network bandwidth. Second, each application has to 
retrieve the CRL periodically, parse the CRL, and allo- 
cate storage for the CRL. Then, the application needs 
to carry out a linear search of the CRL for the public key 
certificate serial number when the application verifies 
each public key certificate. As a result, conventional 
PKIs do not scale beyond a few thousand users. 
[0008] One solution proposed to alleviate the linear 
search problem is to partition CRLs. The serial number 
of the public key certificate determines where the CRL 
partition is located when the public key certificate is re- 
voked. With partitioned CRLs, the application still has to 
retrieve and store the entire CRL or else the application 
needs to fetch a CRL partition in order to verify a certif- 
icate. Since certificate verification is a likely critical path, 
fetching a CRL partition impacts the time it takes to run 
the application. 

[0009] An on-line certificate status protocol (OCSP) 
operates by permitting the verifier of the public key cer- 
tificate to ask the certificate authority if the certificate is 
currently valid. The certificate authority responds with a 
signed statement. The OCSP allows CRLs to be avoid- 
ed, but requires the verifier to query the certificate au- 
thority as part of the transaction that employs the public 
key certificates. The verifier querying the certificate au- 
thority increases the time it takes to perform the trans- 
action. The OCSP scheme is highly vulnerable to a de- 
nial-of-service attack, where the attacker floods the cer- 
tificate authority with queries. Responding to each query 
is computationally expensive, because each response 
requires a digital signature. 

[0010] In a certificate status proofs scheme, the cer- 
tificate authority maintains a data structure describing 
the set of valid and invalid certificates in the directory. 
For every public key certificate that has not yet expired, 
a short cryptographic proof can be extracted from the 
data structure of the certificate's current status (i.e., val- 
id or invalid). A CRL can essentially be viewed as a cryp- 
tographic proof of invalidity for the public key certificates 
in the CRL, and proof of validity forthose not in the CRL. 
The CRL, however, is not a short proof. The short cryp- 
tographic proof can be obtained by the verifier from the 
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directory, or it can be obtained by the subject and pre- 
sented to the verifier together with the public key certif- 
icate. 

[0011] The Simple Public Key Infrastructure (SPKI) 
working group of the Internet Society and the Internet 
Engineering Task Force has proposed the possibility of 
employing short-lived certificates as a method of achiev- 
ing fine-grain control over the validity interval of a cer- 
tificate. See CM. Ellison, B. Frantz, B. Lampson, R. 
Rivest, B.M. Thomas and T Ylonen, SPKI Certificate 
Theory, Request for Comments 2560 of the Internet En- 
gineering Task Force, September 1 999. The SPKI cer- 
tificate theory reference states that there are cases in 
which a short-lived certificate requires fewer signatures 
and less network traffic than various on-line test options. 
The use of a short-lived certificate always requires fewer 
signature verifications than the use of a certificate plus 
on-line test result. 

[0012] Nevertheless, no practical method of issuing 
short-lived certificates has been proposed. Traditional 
certificates are issued off-line, as part of a process that 
includes subject registration, at the rate of one per year 
peruser. By contrast, short-lived certificates would have 
to be issued on-line at the rate of at least one per day 
per user, and perhaps as often as one every few min utes 
for every user. 

[001 3] The term on-line and the term off-line have par- 
ticular definitions in the context of a PKI. The term on- 
line herein refers to the day-to-day usage of public key 
certificates and key pairs for authentication. The term 
off-line herein refers to the more infrequent establish- 
ment or dissolution of public key bindings, which may 
result in the issuing or revocation of public key certifi- 
cates. For example, the traditional certificate authority 
is off-line, issues CRLs off-line, and places the CRLs in 
a directory for on-line retrieval. The scheme involving 
certificate status proofs also makes use of off-line cer- 
tificate authorities. The OCSP is the only scheme de- 
scribed above that employs an on-line certificate author- 
ity. 

[0014] For reasons stated above and for other rea- 
sons presented in greater detail in the Description of the 
Preferred Embodiment section of the present specifica- 
tion, there is a need for an improved lightweight PKI that 
overcomes the above-described revocation problems 
and efficiently scales well beyond a few thousand users, 
and which can be employed for authentication and/or 
authorization. 

[001 5] The present invention provides a public key in- 
frastructure (PKI) including a subject, an on-line regis- 
tration authority, an off-line credentials server, and a ver- 
ifier. The registration authority issues a first unsigned 
certificate off-line to the subject that binds a public key 
of the subject to long-term identification information re- 
lated to the subject. The registration authority maintains 
a certificate database of unsigned certificates in which 
it stores the first unsigned certificate. The credentials 
server issues a short-term disposable certificate on-line 



to the subject. The short-term disposable certificate 
binds the public key of the subject from the first unsigned 
certificate to the long-term identification information re- 
lated to the subject from the first unsigned certificate. 

5 The credentials server maintains a table that contains 
entries corresponding to valid unsigned certificates 
stored in the certificate database. The subject presents 
the short-term disposable certificate to the verifier for 
authentication and demonstrates that the subject has 

io knowledge of a private key corresponding to the public 
key in the short-term disposable certificate. 
[0016] Figure 1 is a block diagram of a light-weight 
public key infrastructure (PKI) according to the present 
invention employing short-term disposable certificates. 

15 [001 7] Figure 2 is a diagram of an unsigned certificate 
issued from a registration authority of the PKI of Figure 
1. 

[001 8] Figure 3 is a flow diagram of an off-line protocol 
for issuing an unsigned certificate from a registration au- 
20 thority of the PKI of Figure 1 . 

[001 9] Figure 4 is a diagram of a non-structured short- 
term disposable certificate as issued by a credentials 
server of the PKI of Figure 1 . 

[0020] Figure 5 is a flow diagram illustrating an on- 
25 line protocol for issuing a short-term disposable certifi- 
cate from a credentials server of the PKI of Figure 1 . 
[0021] Figure 6 is a flow diagram illustrating an on- 
line protocol-for a subject to demonstrate its identity to 
a verifier of the PKI of Figure 1 . 
30 [0022] Figure 7 is a flow diagram illustrating a protocol 
for a registration authority to revoke an unsigned certif- 
icate for the PKI of Figure 1 . 

[0023] Figure 8 is a block diagram of a light-weight 
PKI employing short-term disposable certificates for au- 
35 thorization according to the present invention. 

[0024] Figure 9 is a diagram of a structured short-term 
disposable certificate as issued by a credentials server 
of the PKI of Figure 8. 

[0025] Figure 1 0 is a flow diagram illustrating an on- 
40 line protocol for issuing a structured short-term dispos- 
able certificate from a credentials server of the PKI of 
Figure 8. 

[0026] Figure 11 is a flow diagram illustrating an on- 
line protocol used by a subject to demonstrate its identity 

45 to a verifier of the PKI of Figure 8. 

[0027] Figure 12 is a block diagram of a distributed 
certificate authority having distributed credentials serv- 
ers according to the present invention. 
[0028] Figure 1 3 is a PKI for web server certificate ap- 

50 plications according to the present invention. 

[0029] Figure 1 4 is a flow diagram illustrating a proto- 
col for web server certificate applications for the PKI of 
Figure 13. 

[0030] Figure 15 is a block diagram of an enterprise 
55 PKI according to the present invention. 

[0031] Figure 1 6 is a flow diagram illustrating an au- 
thorization protocol for the enterprise PKI of Figure 17. 
[0032] Figure 1 7 is a block diagram of a computer sys- 
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tern and a corresponding computer readable medium 
incorporating one or more main software program com- 
ponents of a PKI according to the present invention. 
[0033] In the following detailed description of the pre- 
ferred embodiments, reference is made to the accom- 
panying drawings which form a part hereof, and in which 
is shown by way of illustration specific embodiments in 
which the invention may be practiced. It is to be under- 
stood that other embodiments may be utilized and struc- 
tural or logical changes may be made without departing 
from the scope of the present invention. The following 
detailed description, therefore, is not to be taken in a 
limiting sense, and the scope of the present invention is 
defined by the appended claims. 
[0034] A light-weight public key infrastructure (PKI) 
according to the present invention is illustrated generally 
at 30 in Figure 1 . PKI 30 includes several main compo- 
nents which are each a software program. The main 
software program components of PKI 30 run on one or 
more computer systems. In one embodiment, each of 
the main software program components runs on its own 
computer system. 

[0035] A certificate authority 32 issues short-term dis- 
posable certificates to one or more subjects, such as 
subject 34. Subject 34 is a user which owns a public key 
contained in the short-term disposable certificate and 
uses the short-term disposable certificate to demon- 
strate the subject's identity to one or more verifiers, such 
as verifier 36, by demonstrating that the subject has 
knowledge of a private key corresponding to the public 
key in the short-term disposable certificate. Verifier 36 
is a user which relies on the short-term disposable cer- 
tificate presented by subject 34 to verify that subject 34 
is the subject of the short-term disposable certificate and 
that the attributes contained in the short-term disposa- 
ble certificate apply to subject 34. In some embodiments 
of PKI 30, the same user can play the role of subject 34 
and verifier 36 in different situations. 
[0036] PKI 30 does not issue traditional long-term cer- 
tificates, such as issued by conventional PKIs. Tradi- 
tional long-term certificates typically have a validity pe- 
riod defined by an expiration date, which is a substantial 
period from the issue date, such as one year from the 
issue date. A conventional certificate authority needs to 
revoke a traditional long-term certificate if the public key 
certificate binding becomes invalid before the expiration 
date. As discussed in the Background of the Invention 
section of the present specification, a variety of methods 
have been used to revoke traditional long-term certifi- 
cates, such as by using a certificate revocation list (CRL) 
or an on-line certificate status protocol (OCSP). 
[0037] By contrast to traditional long-term certificates, 
the short-term disposable certificates issued by certifi- 
cate authority 32 according to the present invention are 
not subject to revocation. The short-term disposable 
certificates are referred to as being disposable, because 
subject 34 can throw them away after a few uses. As a 
result, in one embodiment of the present invention, the 



short-term disposable certificates are stored in volatile 
memory and are not saved to a disk. PKI 30 is referred 
to as being a lightweight PKI because it is substantially 
simpler and more efficient than a conventional PKI. 
5 [0038] A short-term disposable certificate is herein 
defined as a public key certificate that binds the sub- 
ject's public key to one or more names or identifiers and 
has a short validity period determined by an expiration 
date/time. An example validity period for a short-term 
10 disposable certificate is one day, a few hours : or even 
a few minutes. Since the validity period is quite short, 
revocation is not necessary. Subject 34 requests a fresh 
short-term disposable certificate as needed and submits 
it to verifier 36. Verifier 36 only needs to check the ex- 
's piration date/time to verify that the short-term disposa- 
ble certificate is valid. 

[0039] From the point of view of verifier 36, the use of 
short-term disposable certificates is a much better 
scheme than using traditional long-term certificates, be- 

20 cause verifier 36 only has to verify a signature of the 
short-term disposable certificate and check the expira- 
tion date/time of the short-term disposable certificate. 
Since the certificate validation work of verifier 36 is likely 
to be a critical path in the overall work of verifier 36, 

25 short-term disposable certificates are a good solution for 
the verifier. In many cases, the verifier is a performance 
bottleneck and thus short-term disposable certificates 
are a good overall solution for PKI 30. 
[0040] Certificate authority 32 includes a registration 

30 authority 38 that maintains a certificate database (DB) 
40 containing unsigned certificates. Certificate authority 
32 also includes a credentials server 42 that maintains 
a hash table (HT) 44 containing cryptographic hashes 
of unsigned certificates. 

35 [0041] Registration authority 38 is an off-line compo- 
nent of certificate authority 32 and is responsible for sub- 
ject registration and for maintaining certificate database 
40. Each unsigned certificate in certificate database 40 
binds a public key of a subject to one or more attributes 

^o that uniquely identify the subject. 

[0042] Credentials server 42 is an on-line component 
of certificate authority 32 and is responsible for issuing 
the short-term disposable certificates and for maintain- 
ing the list of cryptographic hashes of currently valid un- 

45 signed certificates in hash table 44. Each cryptographic 
hash in hash table 44 is computed from an unsigned 
certificate using an agreed upon collision-resistant hash 
function, such as SHA-1 or MD5. Hash table 44 is es- 
sentially a list of the currently valid unsigned certificates 

50 which is keyed by the cryptographic hash. Cryptograph- 
ic hashes function well as keys for hash table 44, be- 
cause cryptographic hashes behave statically as ran- 
dom quantities. 

[0043] Subject 34 has a private- key 46 stored in a se- 
55 cure storage medium 48, such as a smartcard or secure 
software wallet. Subject 34 also has a public key math- 
ematically associated with private key 46. Subject 34 
registers the public key corresponding to private key 46 
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with registration authority 38 by sending the public key 
and one or more attributes that uniquely identify subject 
34's identity to registration authority 38 and demonstrat- 
ing that the identification attributes apply to subject 34. 
Examples of such identification attributes include name, 
social security number, and emptoyee number. 
[0044] The components of PKI 30 are linked by one 
or more computer networks. A network connection 50 
couples credentials server 42 and subject 34. A network 
connection 52 couples subject 34 and verifier 36. Net- 
work connections 50 and 52 are shown as solid lines in 
Figure 1 and are used for on-line communications. A 
network connection 54 couples registration authority 38 
and subject 34. A network connection 56 couples reg- 
istration authority 38 and credentials server 42. Network 
connections 54 and 56 are represented as dotted lines 
in Figure 1 and are used for off-line communications. 
Registration authority 38 is only involved in off-line com- 
munications and communicates through off-line net- 
work connections 54 and 56. On the other hand, cre- 
dentials server 42 is involved in on-line communications 
through network connection 50. 
[0045] One embodiment of an unsigned certificate is- 
sued by registration authority 38 is illustrated generally 
at 60 in Figure 2. Unsigned certificate 60 includes a me- 
ta-data (MD) field 61 containing data about unsigned 
certificate 60 itself rather than data related to the sub- 
ject. Examples of data stored in meta-data field 61 in- 
clude serial number and issuer name. Unsigned certifi- 
cate 60 includes a subject's public key (PK) 62. Un- 
signed certificate 60 includes long-term identification in- 
formation (LTI) field 63 containing attributes uniquely 
identifying subject 34, such as the subject's name, the 
subject's social security number, or the subject's em- 
ployee number. 

[0046] Unsigned certificate 60 optionally includes a 
long-term expiration (EXP) field 64 which contains a 
date/time of expiration for unsigned certificate 60. The 
expiration date/time contained in long-term expiration 
field 64 is useful for administrative purposes, but is not 
required for proper functioning of PKI 30. By contrast, 
in a conventional PKI, the expiration date is required to 
reduce the size of the CRL as revoked certificates reach 
their expiration dates. Unsigned certificate 60 optionally 
includes a duration (DUR) field 65 that specifies a dura- 
tion for the validity period of any short-term disposable 
certificates issued against unsigned certificate 60. 
[0047] An off-line protocol for issuing unsigned certif- 
icate 60 from registration authority 38 is illustrated gen- 
erally at 100 in Figure 3. At step 102, subject 34 sends 
its public key and one or more attributes that uniquely 
identify subject 34 to registration authority 38. 
[0048] At step 103, subject 34 demonstrates knowl- 
edge of the private key 46 associated with the subject 
34's public key. Step 103, is performed in a way that 
depends on the cryptosystem for which the private-pub- 
lic key pair has been generated by subject 34. For ex- 
ample, in a digital signature cryptosystem, subject 34 



demonstrates knowledge of the private key 46 by using 
private key 46 to digitally sign a quantity derived from a 
random quantity generated by registration authority 38. 
Registration authority 38 then verifies this digital signa- 

5 ture using subject 34's public key. 

[0049] At step 1 04, subject 34 demonstrates to regis- 
tration authority 38, by out-of-band administrative 
means, that the identification attributes sent in step -1 02 
apply to subject 34. 

10 [0050] At step 106, registration authority 38 creates 
unsigned certificate 60 and stores unsigned certificate 
60 in certificate database 40. At step 108. registration 
authority 38 sends unsigned certificate 60 to subject 34. 
[0051 ] At step 110, registration authority 38 computes 

'5 a cryptographic hash of unsigned certificate 60 using an 
agreed upon collision -resistant hash function, such as 
SHA-1 or MD5. In step 110, registration authority 38 
sends the computed cryptographic hash of unsigned 
certificate 60 to credential server 42 over network con- 

20 nection 56, which provides data integrity protection, 
such as with a Secure Sockets Layer (SSL) connection. 
[0052] At step 112, credentials server 42 stores the 
cryptographic hash of unsigned certificate 60 computed 
in step 110 in hash table 44. 

25 [0053] One embodiment of a short-term disposable 
certificate as issued by credentials server 42 is illustrat- 
ed generally at 70 in Figure 4. Short-term disposable 
certificate 70 includes a meta-data (MD) field 71 con- 
taining data about short-term disposable certificate 70 

30 rather than the subject of short-term disposable certifi- 
cate 70. Short-term disposable certificate 70 includes a 
public key (PK) 72 which is the same public key as public 
key 62 of unsigned certificate 60. The subject of un- 
signed certificate 60 and short-term disposable certifi- 
es cate 70 has only one private-public key pair associated 
with private key 46 stored in smartcard or secure soft- 
ware wallet 48. Short-term disposable certificate 70 in- 
cludes long-term identification information (LTI) field 73 
containing attributes uniquely identifying subject 34. 

40 Long-term identification information field 73 is identical 
to long-term identification information field 63 of un- 
signed certificate 60. 

[0054] Short-term disposable certificate 70 also in- 
cludes a short-term expiration (EXP) field 76 that spee- 
ds jfies a date and time of expiration for a short-term dis- 
posable certificate 70. In one embodiment where un- 
signed certificate 60 contains a duration field 65 that 
specifies a duration for the validity period of the short- 
term disposable certificates issued therefrom, the date 
so and time specified by short-term expiration field 76 is 
obtained by adding the duration specified by duration 
field 65 to the date and time at which short-term dispos- 
able certificate 70 is issued by credentials server 42. In 
one embodiment, the duration of the validity period of 
55 short-term disposable certificate 70 is not explicitly 
specified by a duration field 65 in unsigned certificate 
60. In this embodiment, the duration of the validity period 
of short-term disposable certificate 70 is set by a policy. 
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[0055] Short-term disposable certificate 70 also in- 
cludes a signature field 77 containing a signature of cre- 
dentials server 42. The signature in signature field 77 is 
made by credentials server 42 on the sequence of fields 
71 , 72, 73 ; and 74, as well as, if necessary, the specifi- 
cation of the cryptosystem that has been used to pro- 
duce the signature and must be used to verify the sig- 
nature. 

[0056] In one embodiment, short-term disposable 
certificate 70 is implemented with an X.509v3 certificate. 
[0057] An on-line protocol for issuing a short-term dis- 
posable certificate 70 to subject 34 from credentials 
server 42 against unsigned certificate 60 is generally il- 
lustrated at 200 in Figure 5. At step 202, subject 34 
sends a message to credentials server 42 containing 
unsigned certificate 60 and requesting that a short-term 
disposable certificate be issued against unsigned certif- 
icate 60. 

[0058] At step 204 : credentials server 42 computes a 
cryptographic hash of unsigned certificate 60 by the 
agreed upon collision-resistant hash function. In step 
204, credentials server 42 then verifies that the comput- 
ed cryptographic hash is present in hash table 44. At 
step 206, credentials server 42 creates short-term dis- 
posable certificate 70 and sends short-term disposable 
certificate 70 to subject 34. 

[0059] In step 204, credentials server 42 performs the 
hash table 44 look-up with an efficient and computation- 
ally inexpensive operation. The signature operation per- 
formed by credentials server 42 in step 206 to create 
short-term disposable certificate 70, however, is a com- 
putationally expensive operation. Nevertheless, step 
206 with the computationally expensive signature oper- 
ation is only performed if the look-up of hash table 44 
succeeds. The impact of a denial-of-service attack 
against credentials server 42 is reduced by only per- 
forming step 206 if the look-up in step 204 succeeds. 
[0060] An on-line protocol employed by subject 34 to 
demonstrate its identity to verifier 36 is illustrated gen- 
erally at 300 in Figure 6. At step 302, subject 34 sends 
the issued short-term disposable certificate 70 to verifier 
36. At step 304, verifier 36 verifies that the expiration 
date and time specified in short-term expiration field 76 
of short-term disposable certificate 70 has not been 
reached. 

[0061 ] At step 306, verifier 36 uses a public key of cre- 
dentials server 42 to verify the signature in signature 
field 77 of short-term disposable certificate 70. Verifier 
36 knows the public key of credentials server 42 either 
directly or through certification by a higher certificate au- 
thority. 

[0062] At step 308, subject 34 demonstrates knowl- 
edge of the private key 46 associated with the public key 
72 contained in short-term disposable certificate 70. 
Step 308 is performed in a way that depends on the 
cryptosystem for which the private/public key pair has 
been generated by subject 34. For example, in a digital 
signature cryptosystem, subject 34 demonstrates 



knowledge of the private key 46 by using private key 46 
to digitally sign a quantity derived from a random quan- 
tity generated by verifier 36. Verifier 36 then verifies this 
digital signature using the public key 72 in short-term 

5 disposable certificate 70. 

[0063] Subject 34 can delete short-term disposable 
certificate 70 when the short-term disposable certificate 
expires, because subject 34 can obtain a new short- 
term disposable certificate by sending the unsigned cer- 

io tif icate to credentials server 42. In one embodiment sub- 
ject 34 stores short-term disposable certificate in volatile 
memory and does not save it to disk. 
[0064] An off-line protocol for revoking unsigned cer- 
tificate 60 is illustrated generally at 400 in Figure 7. Off- 

'5 line protocol 400 is performed when subject 34's private 
key 46 is compromised or the identification attributes in 
long-term identification information field 63 no longer 
apply to subject 34, because in either case the binding 
of public key 62 to the identification attributes is invalid. 

20 [0065] At step 402, registration authority 38 retrieves 
unsigned certificate 60 from certificate database 40 and 
computes a cryptographic hash of unsigned certificate 
60 using the agreed upon collision-resistant hash func- 
tion. In one embodiment, registration authority 38 marks 

25 unsigned certificate 60 in certificate database 40 as be- 
ing invalid, for auditing purposes. In an alternative em- 
bodiment, where retention of unsigned certificate 60 in 
certificate database 40 is not required for auditing pur- 
poses, registration authority 38 deletes unsigned certif- 

30 icate 60 from certificate database 40. 

[0066] At step 404, registration authority 38 sends a 
message to credentials server 42 containing the cryp- 
tographic hash of unsigned certificate 60 computed in 
step 402. The message sent in step 404 also requests 

35 that credentials server 42 remove the corresponding 
cryptographic hash of unsigned certificate 60 from hash 
table 44. 

[0067] At step 406, credentials server 42 removes the 
cryptographic hash of unsigned certificate 60 from hash 

40 table 44 which corresponds to the cryptographic hash 
sent in the message from registration authority 38 in 
step 404. After step 406 is completed, credentials server 
42 no longer issues short-term disposable certificates 
70 against unsigned certificate 60. Consequently, once 

45 protocol 400 has been executed, neither subject 34 nor 
an attacker can obtain a short-term disposable certifi- 
cate by presenting unsigned certificate 60 to credentials 
server 42. 

[0068] An alternate embodiment light-weight PKI ac- 
50 cording to the present invention is illustrated generally 
at 30' in Figure 8. The PKI 30' components 32', 34', 36', 
38\ 40', 42\ 44', 46', 48', 50', 52', 54', and 56' generally 
operate and are generally coupled substantially the 
same as the corresponding PKI 30 components 32, 34, 
55 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, and 56 described 
above. 

[0069] PKI 30", however, includes a directory 90. In 
one embodiment, directory 90 is a light-weight directory 
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access protocol (LDAP) directory. PKI 30" also includes 
a network connection 92 to couple credentials server 42* 
to directory 90 to permit credentials server 42' to access 
directory 90. Credentials server 42' obtains short-term 
authorization information stored in directory 90. Creden- 
tials server 42' adds the short-term authorization infor- 
mation obtained from directory 90 to short-term dispos- 
able certificates issued by credentials server 42', to cre- 
ate short-term credentials certificates which can be em- 
ployed for authorization of subject 34'. 
[0070] The short-term authorization information data 
contained in directory 90 relates to attribute or authori- 
zation information about subject 34'. Example short- 
term authorization information includes expense author- 
ization limit for an enterprise application, co-payment 
amount for an insurance application, disk storage quota 
for an Information Technology (IT) application, and user 
ID plus Group ID for Unix access application. 
[0071 ] In PKI 30', verifier 36' is an application program 
running on a server computer system and subject 34' is 
a client program that uses the application. 
[0072] Unsigned certificates issued by registration 
authority 38' are substantially similar to the unsigned 
certificates issued by registration authority 38, such as 
unsigned certificate 60 of Figure 2. 
[0073] PKI 30' employs off-line protocol 100 illustrat- 
ed in Figure 3 for issuing unsigned certificate 60 from 
registration authority 38. In addition, PKI 30' employs 
off-line protocol 400 illustrated in Figure 7 for registration 
authority 38' to revoke unsigned certificate 60. 
[0074] One embodiment of a structured short-term 
disposable certificate issued by credentials server 42' is 
illustrated generally at 80 in Figure 9. Short-term dispos- 
able certificate 80 is a structured certificate. 
[0075] Structured short-term disposable certificate 80 
includes a meta-data field (MD) field 81 , a public key 
(PK) 82, a short-term expiration field 86, and a signature 
field 87, which are substantially similar to meta-data field 
71 , public key 72, short-term expiration field 76 and sig- 
nature field 77 of non-structured short-term disposable 
certificate 70 of Figure 4. Structured short-term dispos- 
able certificate 80, however, includes folders 88a 
through 88n, which respectively correspond to applica- 
tions 36'a through 36'n . For every verifier/application 36' 
that the subject/client 34' can access, as specified, for 
example, by a user profile, there is a cryptographic fold- 
er 88. Each cryptographic folder 88 contains long-term 
identification information 83 and/or short-term authori- 
zation information 89 as required by the corresponding 
verifier/application 36' to make authorization decisions 
about the subject/client 34'. In one embodiment, struc- 
tured short-term disposable certificate 80 is implement- 
ed by adding a folder extension to an X.509v3 certifi- 
cate. 

[0076] An on-line protocol for issuing a structured 
short-term disposable certificate 80 to subject/client 34' 
from credentials server 42' against unsigned certificate 
60 is generally illustrated at 500 in Figure 10. At step 



502, subject/client 34' sends a message to credentials 
server 42' containing unsigned certificate 60 and re- 
questing that a short-term disposable certificate be is- 
sued against unsigned certificate 60. 

s [0077] At step 504, credentials server 42' computes a 
cryptographic hash of unsigned certificate 60 with an 
agreed upon collision-resistant hash function. In step 
504, credentials server 42' then verifies that the com- 
puted cryptographic hash is present in hash table 44'. 

10 [0078] At step 506, credentials server 42' accesses 
directory 90 via network connection 92 and obtains 
short-term authorization information for structured 
short-term disposable certificate 80. 
[0079] At step 508, credentials server 42* combines 

'5 the short-term authorization information obtained from 
directory 90 in step 506 with the identification attributes 
in long-term identification information field 63 of un- 
signed certificate 60. In step 508, credentials server 42' 
creates a cryptographic folder 88 for each verifier/appli- 

20 cation 36' that can be accessed by subject/client 34', 
where each cryptographic folder 88 contains all the 
long-term identification information and/or short-term 
authorization information required by verifier/application 
36' to make authorization decisions about subject/client 

25 34\ in step 508, credentials server 42' uses the crypto- 
graphic folders 88 to create structured short-term dis- 
posable certificate 80. 

[0080] At step 51 0, credentials server 42' sends struc- 
tured short-term disposable certificate 80 to subject/cli- 
30 ent 34', with all of the short-term disposable certificate's 
folders open. 

[0081] An on-line protocol for authorizing subject/cli- 
ent 34' is illustrated generally at 600 in Figure 11 . On- 
line protocol 600 is employed by subject/client 34* to 

35 demonstrate its identity to verifier/application 36'. On- 
line protocol 600 is also used by verifier/application 36' 
to make authorization decisions concerning subject/cli- 
ent 34\ such as allowing/denying access or authorizing 
specific transactions. 

40 [0082] At step 602, subject/client 34" closes all folders 
88 in structured short-term disposable certificate 80, ex- 
cept the folder that contains the necessary identification/ 
authorization information 83/89 required by verifier/ap- 
plication 36' to make authorization decisions concerning 

45 subject/client 34'. At step 604, subject/client 34' sends 
structured short-term disposable certificate 80 to verifi- 
er/application 36'. 

[0083] At step 606, verifier/application 36' verifies that 
the expiration date/time specified in expiration field 86 
50 of structured short-term disposable certificate 80 has 
not expired. 

[0084] At step 608, verifier/application 36' uses a pub- 
lic key of credentials server 42' to verify the signature in 
signature field 87 of structured short-term disposable 
55 certificate 80. Verifier/application 36' knows the public 
key of credentials server 42' either directly or through 
certification by a higher certificate authority. 
[0085] At step 61 0 S subject/client 34* demonstrates 
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knowledge of the private key 46' associated with the 
public key 82 of structured short-term disposable certif- 
icate 80. Step 610 is performed in a way that depends 
on the cryptosystem for which the private/public key pair 
has been generated by subject/client 34'. For example, 
in a digital signature cryptosystem, subject/client 34* 
demonstrates knowledge of the private key 46' by using 
private key 46' to digitally sign a quantity derived from a 
random quantity generated by verifier/application 36*. 
Verifier/application 36' then verifies this digital signature 
using the public key 82 of structured short-term dispos- 
able certificate 80*. 

[0086] At step 61 2, verifier/application 36* extracts the 
identification/authorization information 83/89 contained 
in the open folder 88 of structured short-term disposable 
certificate 80. In step 612, verifier/application 36' then 
uses the identification/authorization information 83/89 
to make authorization decisions concerning subject/cli- 
ent 34'. 

[0087] On-line protocol 600 for authorizing subject/cli- 
ent 34' utilizes structured short-term disposable certifi- 
cate 80 having one folder for each application that may 
be accessed by subject/client 34' as determined by a 
user profile. This ensures that each application only has 
access to authorization information that it requires. Nev- 
ertheless, the authorization performed by PKI 30' can 
be implemented with non-structured short-term dispos- 
able certificates, where multiple non-structured short- 
term disposable certificates are employed in place of 
one structured short-term disposable certificate 80. 
[0088] The PKI 30/30* according to the present inven- 
tion is greatly simplified and substantially more efficient 
than conventional PKIs. For example, applications only 
need to use the short-term disposable certificate for au- 
thentication and/or authorization. The unsigned certifi- 
cate 60, which replaces the traditional long-term certif- 
icate., can be reserved for use by the subject when re- 
questing a short-term disposable certificate. Since the 
unsigned certificate 60 is not used by applications, it 
does not need to be signed. Instead of signing the un- 
signed certificate 60, the credentials server keeps the 
cryptographic hash table 44, which contains the crypto- 
graphic hashes of the unsigned certificates that are cur- 
rently valid. In this way, certificate revocation is per- 
formed simply by removing the cryptographic hash of 
the unsigned certificate from hash table 44. Therefore, 
unlike conventional PKIs, there is no signature required, 
no expiration date required, and no need for CRLs for 
unsigned certificate 60 of the PKI 30/30' according to 
the present invention. 

[0089] PKI 30/30' requires a certificate status check 
somewhat like the on-line certificate status check re- 
quired by OCSP. The certificate status check of PKI 
30/30' according to the present invention, however, oc- 
curs when the subject requests the short-term disposa- 
ble certificate, rather than when the subject accesses 
the application, such as required by OCSP. 
[0090] A distributed certificate authority 1 32 for use in 



14 

PKI 30/30' according to the present invention is illustrat- 
ed in Figure 12. Distributed certificate authority 132 in- 
cludes a registration authority 138 having a certificate 
database 140 which communicates with a distributed 

5 credentials server 142. 

[0091] Distributed credentials server 142 includes 
credentials servers 142a through 142n. Each creden- 
tials server 142 includes a corresponding hash table 
partition 144. In one embodiment, cryptographic hash 

10 table 144 is partitioned into hash table partitions 144a 
through 144n according to a value of some of the bits of 
the cryptographic hash. In a PKI 30/30* employing dis- 
tributed certificate authority 132 having distributed cre- 
dentials servers 1 42a- 1 42n, the subject sends a request 

15 for a short-term disposable certificate directly to the cor- 
rect hash table partition 144. 

[0092] Certificate authority 1 32 is further optimized by 
directly coupling each credentials server 142 with its 
own replica of directory 1 90. 

20 [0093] The PKI 30/30' according to the present inven- 
tion is highly scalable because many bottlenecks of con- 
ventional PKIs are removed. The unsigned certificates 
60 employed by PKI 30/30* do not expire and do not 
have to be renewed periodically. In addition, CRLs are 

25 not used. No significant bottlenecks have been intro- 
duced with PKI 30/30'. 

[0094] One potential bottleneck of PKI 30/30' is that 
the credentials server 42/427142 issues short-term dis- 
posable certificates very often, such as once a day, eve- 

30 ry few hours : or even every few minutes. This frequency 
of issuing short-term disposable certificates from the 
credentials server according to the present invention, 
however, is not a significant bottleneck, because the 
hash table can be partitioned, such as hash table por- 

35 tions 144a-144n of the distributed certificate authority 
132 illustrated in Figure 12 and the credentials server 
can be replicated as required, such as credentials serv- 
ers 142a-142n of distributed certificate authority 132. 
[0095] Another potential bottleneck with PKI 30/30' is 

40 the certificate database 40/40' of registration authority 
38/38'. However, certificate database 40/40' is not a sig- 
nificant bottleneck, because the certificate database is 
only accessed when unsigned certificates 60 are issued 
or revoked. Certificate database 40/40' can be imple- 

45 mented using a relational database management sys- 
tem (DBMS), which can handle millions of unsigned cer- 
tificates. 

[0096] Another potential bottleneck with PKI 30/30* is 
directory 90. Directory 90 is not a significant bottleneck, 

50 because directory 90 can be replicated to make it pos- 
sible to handle millions of users. In addition, LDAP traffic 
to directory 90 is significantly reduced, since applica- 
tions do not access directory 90 to make authorizations 
decisions, since all necessary authorization information 

55 is contained in short-term disposable certificate 80 in the 
embodiment where PKI 30' is used for authorizing the 
subject. Therefore, PKI according to the present inven- 
tion can scale to millions of users. 
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Example Applications of PKl According to the Present 
Invention 

[0097J The PKl according to the present invention can 
be used advantageously in a broad range of applica- 
tions. The following two examples provide only two of 
numerous applications for the PKl according to the 
present invention. 

Web Server Certificates 

[0098] A PKl according to the present invention for a 
web server certificate application Is illustrated generally 
at 730 in Figure 13. PKl 730 includes a certificate au- 
thority 732 (with credentials server), a web server/sub- 
ject 734 , and a browser/verifier 736, which are all cou- 
pled through an Internet 731. 

[0099] PKl 730 does not use short-term authorization 
information in its short-term disposable certificate. 
Therefore, a suitable short-term disposable certificate 
for PKl 30 is short-term disposable certificate 70 illus- 
trated in Figure 4, which is a n on -structured certificate 
(i.e., no folders). In addition, the short-term disposable 
certificate 70 employed in PKl 730 contains no confiden- 
tial information. 

[01 00] A web server certificate protocol for PKl 730 is 
illustrated generally at 700 in Figure 14. At step 702, 
certificate authority 732 issues an unsigned certificate 
60 for web server 734's public key. The unsigned certif- 
icate is not signed, is retrieved only once, and never ex- 
pires. 

[0101] At step 704, web server 734 requests a non- 
structured short-term disposable certificate 70. The un- 
signed certificate 60 is sent as part of the web server 
request. In one embodiment, meta-data field 61 speci- 
fies the duration of the validity period of the to be issued 
short-term disposable certificate 70. 
[0102] At step 706, certificate authority 732 verifies 
the unsigned certificate 60 provided by web server 734 
and issues a corresponding short-term disposable cer- 
tificate 70. In step 706, short-term disposable certificate 
70 is derived from the unsigned certificate 60 by adding 
an expiration time in short-term expiration field 76, such 
as 24 hours after the present time, and by adding the 
certificate authority 732's signature in signature field 77. 
[01 03] At step 708, web server 734 sends short-term 
disposable certificate 70 to browser 736. Step 708 is 
part of a protocol for establishing an SSL connection. At 
step 710, a handshake is performed between browser 
736 and web server 734. In step 710, web server 734 
demonstrates to browser 736 that web server 734 
knows the private key corresponding to the public key 
in short-term disposable certificate 70. Step 710 is also 
part of the protocol for establishing the SSL connection. 
[0104] At step 712 a secure connection is made be- 
tween browser 736 and web server 734. In step 712, an 
example secure connection is SSL which provides data 
integrity, which prevents connection high-jacking and 



other man-in-the-middle attacks. SSL also provides en- 
cryption to ensure confidentiality. 
[0105] In conventional web server certificate PKl ap- 
plications, the web server's certificate can not be re- 

5 voked or the browser must access the certificate author- 
ity to obtain the latest CRL or check the certificate status 
via OCSP. Having the browser of a conventional web 
server certificate PKl access the certificate authority is 
highly undesirable, because this access to the certifi- 

10 cate authority introduces a delay which is perceived by 
the user as additional delay in accessing the web server. 
In addition, this browser access of the certificate author- 
ity possibly prevents access to the web server if the cer- 
tificate authority is down. Moreover, CRL or OCSP 

15 processing requires additional code in the browser 
which may not fit in the browser if the browser runs on 
a small network appliance. 

[0106] By contrast to the conventional PKl, in PKl 730 
according to the present invention, certificate authority 

20 732 can revoke the web server's unsigned certificate 60. 
After certificate authority 732 has revoked unsigned cer- 
tificate 60, web server 734 is no longer able to obtain 
short-term disposable certificates, and browsers 736 
are not able to establish SSL connections to web server 

25 734. Moreover, browser 736 does not use CRLs or OC- 
SP, so browser access of certificate authority 732 to ob- 
tain the latest CRL or check the certificate status via OC- 
SP is not required with PKl 730. 

30 Enterprise PKl 

[0107] An enterprise PKl according to the present in- 
vention is illustrated generally at 930 in Figure 15. En- 
terprise PKl 930 includes a certificate authority 932 (with 

35 credentials server) coupled to a client 934 via a network 
connection 950. Certificate authority 932 is coupled to 
a LDAP directory 990 via a network connection 992. Cli- 
ent 934 has access to a user's private key 946 stored in 
a smartcard 948. Client 934 is coupled to applications 

40 936a, 936b, and 936c via network connections 952a, 
952b, and 952c respectively. 

[0108] The network connections of enterprise PKl 930 
are deemed secure or are protected by host-to-host 
IPSEC. Client 934's short-term disposable certificate is 

45 a structured certificate, such as structured short-term 
disposable certificate 80 illustrated in Figure 9. Struc- 
tured short-term disposable certificate 80 in enterprise 
PKl 930 contains short-term authorization information 
that is possibly confidential. 

so [0109] An authorization protocol for enterprise PK! 
930 is illustrated generally at 900 in Figure 16. At step 
902, certificate authority 932 issues an unsigned certif- 
icate 60 for the user's public key. Step 902 needs only 
be taken once. At step 904, client 934 submits unsigned 

55 certificate 60 to certificate authority 932. Step 904 is tak- 
en at network logon. 

[0110] At step 906, a handshake between certificate 
authority 932 and client 934 permits client 934 to dem- 
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onstrate to certificate authority 932 that client 934 has 
access to the user's private key 946 stored in smartcard 
948. Step 906 is taken at network logon. At step 908, 
certificate authority 932 obtains short-term authorization 
information from LDAP directory 990. In one embodi- 
ment, LDAP directory 990 is integrated with certificate 
authority 932. Step 908 is taken at network logon. 
[0111] At step 910, certificate authority 932 issues 
structured short-term disposable certificate 80. In step 
910, certificate authority 932 sends the issued struc- 
tured short-term disposable certificate 80 to client 934. 
In an example application of enterprise PKI 930, the 
structured short-term disposable certificate 80 includes 
three folders, one for each application 936a, 936b, and 
936c. All of the folders of structured short-term dispos- 
able certificate 80 are open. Some of the information in 
the folders of structured short-term disposable certifi- 
cate 80 is possibly confidential. Network connections 
952, however, are deemed secure or are protected by 
host-to- host I PS EC. Step 910 is taken at network logon. 
[0112] At step 912, client 934 submits structured 
short-term disposable certificate 80 to the requested ap- 
plication 936. For example, if the requested application 
is 936b, the folder 88b, corresponding to application 
936b, remains open. In this example, the folders 88a 
and 88c of structured short-term disposable certificate 
80, which correspond to applications 936a and 936c, 
are closed. 

[0113] At step 914, a handshake is performed be- 
tween the requested application 936b and client 934. In 
step 914, client 934 demonstrates to application 936b 
that client 934 has access to the user's private key 946 
stored in smartcard 948. 

[0114] The enterprise PKI 930 according to the 
present invention is streamlined compared to conven- 
tional enterprise PKIs. Enterprise PKI 930 does not 
need to use CRLs or OCSP. All information needed to 
make authorizations decisions is contained in structured 
short-term disposable certificate 80. Therefore, applica- 
tions 936 do not need to access LDAP directory 990 to 
make authorizations decisions about client 934. 
[0115] Enterprise PKI 930 can handle millions of us- 
ers. PKI 930 is suitable to provide authentication and 
authorization services for all employees and business 
partners of a corporation of any size. 
[01 1 6] Figure 1 7 illustrates one embodiment of a com- 
puter system 250 and an external computer readable 
medium 252 which can be employed according to the 
present invention to implement one or more of the main 
software program components of a light-weight PKI ac- 
cording to the present invention, such as PKI 30, PKI 
30', PKI 730, PKI 830 and PKI 930. Embodiments of ex- 
ternal computer readable medium 252 include, but are 
not limited to: a CD-ROM, a floppy disk, and a disk car- 
tridge. Any one of the main software program compo- 
nents of a light-weight PKI according to the present in- 
vention can be implemented in a variety of compiled and 
interpreted computer languages. Externa! computer 



readable medium 252 stores source code, object code, 
executable code, shell scripts and/or dynamic link librar- 
ies for any one of the main software program compo- 
nents of a light-weight PKI according to the present in- 

5 vention. An input device 254 reads external computer 
readable medium 252 and provides this data to compu- 
ter system 250. Embodiments of input device 254 in- 
clude but are not limited to: a CD-ROM reader, a floppy 
disk drive, and a data cartridge reader. 

w [0117] Computer system 250 includes a central 
processing unit 256 for executing any one of the main 
software program components of a light-weight PKI ac- 
cording to the present invention. Computer system 250 
also includes local disk storage 262 for locally storing 

'5 any one of the main software program components of a 
light-weight PKI according to the present invention be- 
fore, during, and after execution. Any one of the main 
software program components of a light-weight PKI ac- 
cording to the present invention also utilizes memory 

20 260 within the computer system during execution. Upon 
execution of any one of the main software program com- 
ponents of a light-weight PKI according to the present 
invention, output data is produced and directed to an 
output device 258. Embodiments of output device 258 

25 include, but are not limited to: a computer display de- 
vice, a printer, and/or a disk storage device. 
[0118] Although specific embodiments have been il- 
lustrated and described herein for purposes of descrip- 
tion of the preferred embodiment, it will be appreciated 

so by those of ordinary skill in the art that a wide variety of 
alternate and/or equivalent implementations calculated 
to achieve the same purposes may be substituted for 
the specific embodiments shown and described without 
departing from the scope of the present invention. 

35 Those with skill in the chemical, mechanical, electro- 
mechanical, electrical, and computer arts will readily ap- 
preciate that the present invention may be implemented 
in a very wide variety of embodiments. This application 
is intended to cover any adaptations or variations of the 

40 preferred embodiments discussed herein. Therefore, it 
is manifestly intended that this invention be limited only 
by the claims and the equivalents thereof. 



45 Claims 

1 . A public key infrastructure (PKI) (30) comprising: 
a subject (34); 

50 an off-line registration authority (38) for issuing 

a first unsigned certificate (60) off-line to the 
subject that binds a public key (62) of the sub- 
ject to long-term identification information (63) 
related to the subject, the registration authority 

55 maintaining a certificate database (40) of un- 

signed certificates in which it stores the first un- 
signed certificate; 

an on-line credentials server (42) for issuing a 



10 



19 

short-term disposable certificate (70) on-line to 
the subject, the short-term disposable certifi- 
cate binds the public key of the subject from the 
first unsigned certificate to the long-term iden- 
tification information related to the subject from s 
the first unsigned certificate, wherein the cre- 
dentials server maintains a table (44) that con- 
tains entries corresponding to valid unsigned 
certificates stored in the certificate database; 
and 10 
a verifier (36) : wherein the subject presents the 
short-term disposable certificate to the verifier 
for authentication and demonstrates that the 
subject has knowledge of a private key (46) cor- 
responding to the public key in the short-term *5 
disposable certificate. 

2. The PKI of claim 1 wherein the short-term disposa- 
ble certificate includes an expiration date/time. 

20 

3. The PKI of claim 2 wherein a validity period from 
when the credentials server issues the short-term 
disposable certificate to the expiration date/time is 
sufficiently short such that the short-term certificate 
does not need to be subject to revocation. 25 

4. The PKI of claim 1 or 2 wherein the short-term dis- 
posable certificate is not subject to revocation. 

5. The PKI of claim 1 wherein the table maintained by 30 
the credentials server is a hash table containing 
cryptographic hashes of valid unsigned certificates 
stored in the certificate database and including a 
cryptographic hash of the first unsigned certificate, 
wherein the subject presents the issued first un- 35 
signed certificate to the credentials server to obtain 

the short-term disposable certificate. 

6. The PKI of claim 1 wherein the registration authority 
and the credentials server are included in a certifi- *o 
cate authority and wherein the certificate authority 

is a distributed certificate authority including at least 
two distributed credentials servers. 

7. The PKI of claim 6 wherein the at least two distrib- *5 
uted credentials servers includes at least two cor- 
responding hash table partitions containing crypto- 
graphic hashes of valid unsigned certificates corre- 
sponding to the unsigned certificates stored in the 
certificate database, wherein one of the hash table so 
partitions contains a cryptographic hash of the first 
unsigned certificate, wherein the subject presents 

the issued first unsigned certificate to one of the at 
least two distributed credentials servers to obtain 
the short-term disposable certificate. ss 

8. The PKI of claim 1 wherein the short-term disposa- 
ble certificate is.a non-structured short-term certifi- 



20 
cate. 

9. The PKI of claim 1 further comprising: 

a directory for storing short-term authorization 
information related to the subject; 
wherein the short-term disposable certificate 
also binds the public key of the subject from the 
first unsigned certificate to the short term au- 
thorization information related to the subject 
from the directory; and 

wherein the subject presents the short-term 
disposable certificate to the verifier for author- 
ization and demonstrates that the subject has 
knowledge of a private key corresponding to 
the public key in the short-term disposable cer- 
tificate. 

10. The PKI of claim 1 further comprising: 

a second verifier; and 

wherein the short-term certificate is a struc- 
tured short-term certificate including: 

a first folder corresponding to the first 
named verifier and containing long-term in- 
formation and short-term information as re- 
quired by the first named verifier; 
a second folder corresponding to the sec- 
ond verifier and containing long-term infor- 
mation and short-term information as re- 
quired by the second verifier; 
wherein the first folder is open and the sec- 
ond folder is closed when the subject 
presents the short-term disposable certifi- 
cate to the first named verifier for authori- 
zation, wherein closing the second folder 
makes its contents not readable by the first 
named verifier; and 

wherein the first folder is closed and the 
second folder is open when the subject 
presents the short-term disposable certifi- 
cate to the second verifier for authorization, 
wherein closing the first folder makes its 
contents not readable by the second veri- 
fier. 

11. The PKI of claim 10 wherein the first folder and the 
second folder are implemented as extension fields 
of an X.509v3 certificate. 

12. The PKI of claim 1 wherein the registration authority 
and the credentials server are included in a certifi- 
cate authority and wherein the certificate authority 
revokes the first unsigned certificate when the bind- 
ing of the subject's public key to the long-term iden- 
tification information related to the subject becomes 
invalid. 
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1 3. The PKI of claim 1 9 wherein the certificate authority 
performs a revocation protocol to revoke the first 
unsigned certificate, the revocation protocol includ- 
ing: 

5 

the registration authority retrieving the first un- 
signed certificate from the certificate database 
and computing a cryptographic hash of the first 
unsigned certificate; 

sending a message from the registration au- io 
thority to credentials server containing the cryp- 
tographic hash of the first unsigned certificate 
and requesting that the credentials server re- 
move the corresponding cryptographic hash of 
the first unsigned certificate from its hash table; '5 
and 

the credentials server removing the crypto- 
graphic hash of the first unsigned certificate 
from its hash table. 

20 

1 4. A method of authenticating a subject (34), the meth- 
od comprising: 

issuing a first unsigned certificate (60) off-line 
to the subject that binds a public key (62) of the 25 
subject to long-term identification information 
(63) related to the subject; 
maintaining a certificate database (40) of un- 
signed certificates off-line including storing the 
first unsigned certificate in the certificate data- 30 
base; 

issuing a short-term disposable certificate (70) 
on-line to the subject, the short-term disposa- 
ble certificate binds the public key of the subject 
from the first unsigned certificate to the long- 35 
term identification information related to the 
subject from the first unsigned certificate: 
maintaining a table (44) on-line that contains 
entries corresponding to valid unsigned certifi- 
cates stored in the certificate database; and *o 
presenting the short-term disposable certificate 
by the subject to a verifier (36) for authentica- 
tion and demonstrating that the subject has 
knowledge of a private key (46) corresponding 
to the public key in the short-term disposable ^ 
certificate. 

15. The method of claim 14 wherein the short-term dis- 
posable certificate includes an expiration date/time. 

50 

16. The method of claim 15 wherein a validity period 
from when the short-term disposable certificate is 
issued to the expiration date/time is sufficiently 
short such that the short-term certificate does not 
need to be subject to revocation. 55 

17. The method of claim 14 or 15 wherein the short- 
term disposable certificate is not subject to revoca- 



tion. 

18. The method of claim 14 wherein the table is main- 
tained by a credentials server and is a hash table 
containing cryptographic hashes of valid unsigned 
certificates stored in the certificate database and in- 
cluding a cryptographic hash of the first unsigned 
certificate, wherein the method further includes: 

presenting the issued first unsigned certificate 
by the subject to the credentials server to obtain the 
short-term disposable certificate. 

1 9. The method of claim 1 4 wherein the short-term dis- 
posable certificate is a non-structured short-term 
certificate. 

20. The method of claim 14 further comprising: 

storing short-term authorization information re- 
lated to the subject in a directory, wherein the 
short-term disposable certificate also binds the 
public key of the subject from the first unsigned 
certificate to the short term authorization infor- 
mation related to the subject from the directory; 
and 

presenting the short-term disposable certificate 
by the subject to the verifier for authorization 
and demonstrating that the subject has knowl- 
edge of a private key corresponding to the pub- 
lic key in the short-term disposable certificate. 

21 . The method of claim 1 4 wherein the short-term cer- 
tificate is a structured short-term certificate includ- 
ing a first folder corresponding to the first named 
verifier and containing long-term information and 
short-term information as required by the first 
named verifier, and including a second folder cor- 
responding to a second verifier and containing long- 
term information and short-term information as re- 
quired by the second verifier, the method further 
comprising: 

closing the second folder and leaving the first 
folder open prior to the presenting step if the 
short-term disposable certificate is presented 
by the subject to the first named verifier for au- 
thorization, wherein closing the second folder 
makes its contents not readable by the first 
named verifier; and 

closing the first folder and leaving the second 
folder open prior to the presenting step if the 
short-term disposable certificate is presented 
by the subject to the second verifier for author- 
ization, wherein closing the first folder makes 
its contents not readable by the second verifier. 

22. The method of claim 14 further comprising: 

revoking the first unsigned certificate when 
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the binding of the subject's public key to the long- 
term identification information related to the subject 
becomes invalid. 

23. The method of claim 22 further comprising: 5 
performing a revocation protocol to revoke the 
first unsigned certificate, the revocation protocol in- 
cluding: 

retrieving the first unsigned certificate from the 10 
certificate database and computing a crypto- 
graphic hash of the first unsigned certificate; 
sending a message containing the crypto- 
graphic hash of the first unsigned certificate re- 
quest that the corresponding cryptographic 1$ 
hash of the first unsigned certificate be re- 
moved from its hash table; and 
removing the cryptographic hash of the first un- 
signed certificate from its hash table. 
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SUBJECT SENDS ITS PUBLIC KEY AND 
IDENTIFICATION ATTRIBUTES TO 
REGISTRATION AUTHORITY 



T 



SUBJECT DEMONSTRATES 
KNOWLEDGE OF THE PRIVATE KEY 
ASSOCIATED WITH ITS PUBLIC KEY 



SUBJECT DEMONSTRATES TO 
REGISTRATION AUTHORITY THAT 
IDENTIFICATION ATTRIBUTES APPLY 
TO SUBJECT 
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REGISTRATION AUTHORITY SENDS 
UNSIGNED CERTIFICATE TO SUBJECT 
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REGISTRATION AUTHORITY 
COMPUTES CRYPTOGRAPHIC HASH OF 
UNSIGNEDCERTIFICATE 
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CREDENTIALS SERVER STORES 
CRYPTOGRAPHIC HASH COMPUTED IN 
STEP 1 10 IN ITS HASH TABLE 
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SUBJECT SENDS MESSAGE TO 
CREDENTIALS SERVER 
CONTAINING UNSIGNED 
CERTIFICATE AND REQUESTING 
THAT A SHORT-TERM DISPOSABLE 
CERTIFICATE BE ISSUED AGAINST 
UNSIGNED CERTIFICATE 



CREDENTIALS SERVER COMPUTES 

THE CRYPTOGRAPHIC HASH OF 
THE UNSIGNED CERTIFICATE AND 
VERIFIES THAT THE COMPUTED 
CRYPTOGRAPHIC HASH IS 
PRESENT IN HASH TABLE 
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CERTIFICATE TO SUBJECT 
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SUBJECT/CLIENT SENDS A MESSAGE TO 
CREDENTIALS SERVER CONTAINING 
UNSIGNED CERTIFICATE AND REQUESTING 
THAT A SHORT-TERM DISPOSABLE 
CERTIFICATE BE ISSUED AGAINST 
UNSIGNED CERTIFIGATE 
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CREDENTIALS SERVER COMPUTES 
CRYPTOGRAPHIC HASH OF UNSIGNED 
CERTIFICATE AND VERIFIES THAT THE 
COMPUTED CRYPTOGRAPHIC HASH IS 
PRESENT IN HASH TABLE 



-504 



CREDENTIALS SERVER ACCESSES THE 
DIRECTORY AND OBTAINS AUTHORIZATION 
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IN STEP 506 AND IDENTIFICATION 
ATTRIBUTES CONTAINED IN THE UNSIGNED 
CERTIFICATE TO CREATE A 
CRYPTOGRAPHIC FOLDER FOR EACH 
VERIFIER/APPLICATION THAT MAY BE 
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CREATES A STRUCTURED SHORT-TERM 
DISPOSABLE CERTIFICATE 



CREDENTIALS SERVER SENDS THE 
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ALL ITS FOLDERS OPEN 
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SUBJECT/CLIENT CLOSES ALL FOLDERS IN 
SHORT-TERM DISPOSABLE CERTIFICATE 
EXCEPT THE FOLDER THAT CONTAINS 
INFORMATION NEEDED BY THE 
VERIFIER/APPLICATION FOR AUTHORIZATION 
OF THE CLIENT 
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VERIFIER/APPLICATION USES THE 
AUTHORIZATION/IDENTIFICATION 
INFORMATION CONTAINED IN THE OPEN 
FOLDER OF THE SHORT-TERM DISPOSABLE 
CERTIFICATE TO MAKE AUTHORIZATION 
DECISIONS CONCERNING THE SUBJECT/CLIENT 
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